An application, such as a database server, may store information on persistent storage devices, such as hard disk drives, so that the application can retrieve and use such information in the future. Because of the physical reality of persistent storage devices, persistent storage devices may be called “physical devices.” On a physical device, information is typically stored in discrete logical units called “blocks.” For example, parts of a single file may be dispersed throughout multiple blocks on one or more physical devices. Each block stores a different part of the file. Each separate physical device may be viewed as a separate component within a storage layer.
Sometimes, an application indirectly interfaces with one or more physical devices through one or more intermediate storage layers that belong to a hierarchy of storage layers. Such a hierarchy of storage layers is also called an input/output (I/O) stack. For example, a database server application may interface directly with a file system. The file system may interface directly with a logical volume manager. The logical volume manager may interface directly with a storage subsystem that provides Redundant Array of Independent Disks (RAID), wherein each Disk is a separate physical device.
Through abstraction, each storage layer in the hierarchy may represent multiple different components of the storage layer as a single physical device. Such abstraction insulates upper storage layers from details that can be managed by lower storage layers. For example, a file may be divided into multiple parts, with each part being “stored” on a different logical volume. An application may instruct a file system to perform operations on the file without expressly indicating which logical volumes store the parts of the file. After receiving the file's identifier from the file system, a logical volume manager can determine which volumes store the parts of the file, and instruct a lower storage layer subsystem to perform corresponding operations on one or more of the relevant parts. Therefore, even though parts of a file may be dispersed throughout multiple logical volumes and multiple physical devices, the dispersion of the parts is transparent to the application that performs operations on the file.
It is useful to know on which physical devices the several blocks of a file are stored. In other words, it is useful to know a mapping between a file and the physical devices that collectively store the file. Such a mapping can be used, for example, to identify input/output bottlenecks. However, due to the multiple intermediate storage layers discussed above, determining such a mapping can be a difficult, if not impossible, task.
For example, a “first storage layer” file system may be a product of a first vendor, a “second storage layer” logical volume manager may be a product of a second vendor, and a “third storage layer” RAID manager may be a product of a third vendor. Each vendor may or may not provide a tool to determine mappings between components of that vendor's storage layer and file parts stored on those components. Where such tools exist, they are not currently designed to work in conjunction with each other. Currently, in storage systems that involve multiple intermediate storage layers, there is no way for an application that only directly interfaces with an uppermost storage layer to determine which physical devices store blocks of a particular file.
In a database, a database object such as a table may be stored within a single file, or divided among multiple files. While a database server application may possess sufficient information to determine a mapping of a database object to one or more files, database server applications are currently unable to determine a mapping of a file to one or more physical devices in storage systems that involve multiple intermediate storage layers. By extension, database server applications are currently unable to determine a mapping of a database object to one or more physical devices in such storage systems.
A technique for determining a mapping of a database object to storage layer components that collectively store the database object is needed.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.